I can merge this PR as a short-term fix. But, as there is already a handful of places in the code where Unit Scope names are being used explicitly but inconsistently, I might suggest expanding on this change to include all RTL units that use Unit Scope Names, like System.SysUtils, System.IOUtils, System.DateUtils, Vcl.xxx, etc. And add a new compiler define to IdCompilerDefines.inc such as USE_UnitScopeNames for better clarity rather than using VCL_XE2_OR_ABOVE.

That makes good sense. I wouldn't have been surprised if you wanted to change the compiler directive I used in this commit; I found it used for similar purposes elsewhere and it seemed to work so thought if nothing else, I'd bring attention to it. I like USE_UnitScopeNames better.

I changed the target branch for this PR, as I'm going to make further changes before merging everything into master.

If you'd like some help making these changes, let me know how you want to go about it and I can put some time into it.

I added additional changes to the add-unit-scope-names branch, let me know what you think or if I missed something. It turned out to be a bit more than I expected.

This last update caused a problem compiling that I didn't expect. I first tried rebuilding the packages in XE8, got an error, thought it might just be an old compiler so tried it in 11 Alexandria but saw the same thing.

The period after "System" in the line below causes the compiler to think it's the end of the file even though it's clearly just in a conditional compilation directive:
uses
{$IFDEF USE_UNITSCOPENAMES}System.{$ENDIF}Classes

It's gotta be changed to:
uses
{$IFDEF USE_UNITSCOPENAMES}System.Classes{$ELSE}Classes{$ENDIF}
for every such instance throughout the code. :-(

I'm working through it and will test-compile under several different versions of Delphi before I commit an update.

On second thought, I'm going to abandon this effort. There are way too many of these; it would be far easier to add unit scope names to all the projects. The reason is that anywhere a unit name prefixes a function or procedure or identifier, it has to be a fully qualified unit name, including the unit scope name (see this DocWiki reference). That means not only do we need these {$IFDEF USE_UNITSCOPENAMES} conditionals in the uses clauses but we also need them anytime we use them in the code, such as calling Windows.Infinite or SysUtils.AnsiPos or System.TimeSpan (all of these and 29 more in the IdGlobal unit alone).

The period after "System" in the line below causes the compiler to think it's the end of the file even though it's clearly just in a conditional compilation directive: uses {$IFDEF USE_UNITSCOPENAMES}System.{$ENDIF}Classes

That's interesting, giving that there were already a few instances of unit scope names being used in this manner, and nobody has complained about this issue before.

it would be far easier to add unit scope names to all the projects.

Probably for the best. On the other hand, I think there are some .dproj files missing from the repo for various versions, and that is the only place that Unit Scope Names can be stored.

The reason is that anywhere a unit name prefixes a function or procedure or identifier, it has to be a fully qualified unit name, including the unit scope name (see this DocWiki reference).

Yes, I saw that, and I think it's quite stupid, IMHO. The compiler should know which units are in the uses clauses and be able to match partially-qualified references to their members. If I have System.SysUtils in the uses clause and refer to something as SysUtils.xxx in the code, it should be able to resolve it as System.SysUtils.xxx without having to code it that way explicitly. It already works this way for unqualified references, I don't see why they couldn't do the same for partially-qualified references. But oh well.

I have updated the branch with code changes. If we still want to pursue project changes instead of code changes, the code changes can be reverted.

Wow, you really went there:

315 files changed, +694 -692 lines changed

You must've used global search and replace with regular expressions or have some custom tool to make all those changes that quickly. I tried a couple of techniques but it was just taking too long so backed it all out.

I think modifying the project options would be cleaner, easier to read the code. I could fill in the missing project files--I have most versions of Delphi installed on VMs back to XE and even Delphi 7 and 2007.

However, I'll build this and see what we get. Probably better to explicitly use the unit names to remove any possibility of ambiguity or remembering to add the unit scopes in future projects.

Oh wait--all you did was change the compiler directive name. It still thinks the "." signifies end of file so we still have the same problem: these won't compile until code like this:
{$IFDEF USE_UNIT_SCOPE_NAMES}System.{$ENDIF}Classes
is changed to:
{$IFDEF USE_UNIT_SCOPE_NAMES}System.Classes{$ELSE}Classes{$ENDIF}

Let me correct myself again--you DID apply this fix to most of the files but there were several more that choked the compile (sorry). I used Claude Code to write a python script to adjust the rest; it found 78 instances in 14 files. I'll create another PR shortly.

You must've used global search and replace with regular expressions or have some custom tool to make all those changes that quickly.

Nope. I'm not good with that stuff. I just used good old fashioned Notepad++ "Find in Files" and copy & pasting.

I think modifying the project options would be cleaner, easier to read the code.

Yup.

I could fill in the missing project files--I have most versions of Delphi installed on VMs back to XE and even Delphi 7 and 2007.

Cool.

I went ahead and merged this particular PR into the master code. We can continue with the other PR to clean things up better.

Sounds good.